Open Bug 1343825 Opened 8 years ago Updated 3 years ago

Allow me to select text in html tree while also improving Drag'n'Drop discoverability

Categories

(DevTools :: Inspector, defect, P3)

54 Branch
defect

Tracking

(firefox54 affected)

Tracking Status
firefox54 --- affected

People

(Reporter: nachtigall, Unassigned)

References

(Blocks 1 open bug)

Details

This is spin-off Comment https://bugzilla.mozilla.org/show_bug.cgi?id=991806#c36 and the Reply https://bugzilla.mozilla.org/show_bug.cgi?id=991806#c38 Use Case: I was digging into some HTML. Collapsing and Expanding different nodes of the nested html tree. Eventually I found why and how our markup was wrongly nested and wanted to communicate this to another developer. To do this, I had to do several "Copy > Outer HTML" and then re-edit again in my Editor and doing all the Collapsing and Expanding again over there. (you can see the end result at https://wordpress.org/support/topic/markup-anderung-zw-1-7-und-1-8-1-notwendig/ N.B. the "..." I had to enter manually) It would have been so much easier if I were able to select the nested html of the Inspector (which I already had laid out the way I wanted it) and could just copy this. But this is not possible because of the Drag'n'Drop feature. I think it would be nice if both, selecting text and Drag'n'Drop, would be possible. 2 ideas: 1st: When <Alt> key is pressed, then text can be selected. Same way you can select text out of a link this way in normal Firefox (http://superuser.com/questions/482266/how-do-i-select-middle-part-of-a-hyper-link). However, this would have severe discoverability problems. OTOH, the drag'n'drop also has discoverability problems (it's not obvious that one can drag'n'drop unless one already knows or one is shown - there's no hint whatsoever) So 2nd, better, idea: Instead of a globally overlaying Drag'n'Drop, add a small drag'n'drop icon handle to the left of a node. This move or drag'n'drop icon handle could only be shown when a line is hovered or selected. This would also solve the discoverability problems of Drag'n'Drop. At the same time, text selection could be allowed. These drag'n'drop handles are quite common and are learnt/understood by users, so I think it would represent a better UX too. See here for example (I did a google image search for "handle drag and drop"): * https://wiki.almworks.com/download/attachments/7471144/issue_handle.png?version=1&modificationDate=1312474509000&api=v2 * http://designingwebinterfaces.com/blog/wp-content/uploads/2009/07/gmail_drag-handle.png (gmail) * http://ui-patterns.vmware.com/sites/default/files/unity/pattern-images/table-drag-drop-interaction-3.png * http://www.jqueryscript.net/images/jQuery-Drag-drop-Sorting-Plugin-For-Bootstrap-html5sortable.jpg
We could simply detect if the user is doing a horizontal movement or a vertical movement. If it's horizontal, we start selecting, otherwise, we start dragging.
@Tim: I guess, this would not work for multiline selection which was my use case. For multiline selection I would just drag down or up (like I do in any editor or firefox itself for text selection). Also for Drag'n'Dropping I can imagine that one might just drag diagonally in a, say, 10% angle up/down which could be considered as vertical by an algorithm. I'd also rather go with an well established UI (a move handle or similar) instead of creating a new (unfamiliar) one that needs to be learnt.
(In reply to Jens from comment #2) > @Tim: I guess, this would not work for multiline selection which was my use > case. For multiline selection I would just drag down or up (like I do in any > editor or firefox itself for text selection). Also for Drag'n'Dropping I can > imagine that one might just drag diagonally in a, say, 10% angle up/down > which could be considered as vertical by an algorithm. I'd also rather go > with an well established UI (a move handle or similar) instead of creating a > new (unfamiliar) one that needs to be learnt. It feels natural to me, you're more likely to do vertical movements when selecting. Of course the algorithm needs to be well-coded to have a tolerance rate (10% angle,...). Opera uses this algorithm for link selection/dragging, and it usually works well. Though I agree this doesn't work too well for multi-line selection.
Inspector bug triage (filter on CLIMBING SHOES).
Priority: -- → P3
Firebug let me select code - a feature I use every day. On the other hand, I never wanted to drag and drop code. In my eyes select should be default behaviour (like in good old Firebug). There could additionally be a button/icon/menu item for Drag'n'Drop.
(In reply to nebo from comment #5) > I never wanted to drag and drop code. While you never needed this feature, some other people do, but see below. > In my eyes select should be default behaviour (like in good old Firebug). > There could additionally be a button/icon/menu item for Drag'n'Drop. That's the second solution Jens proposed and I agree that this may be the best solution regarding UX and discoverability. Tim's idea of detecting whether the user does a horizontal or vertical movement and depending on that either select or start dragging the element is an interesting idea, though is probably not very obvious and may result in bad UX when wanting to select multiple lines. I also agree with Jens that his first idea, using Alt to allow to select the text, while corresponding to the UI on links, is not very discoverable. Sebastian
Product: Firefox → DevTools
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.